Funcionalidades & Vulnerabilidades de GCP poco conocidas para Ingenieros Ofensivos

Author: https://jornadas.ccn-cert.cni.es/es/xixjornadas-programa-general/xix-jornadas-ccn-cert/ponente/carlos-polop

Contexto general

Esta charla va de ataques reales en GCP y de cómo Google maneja (o no maneja) ciertos comportamientos que están en una zona gris entre vulnerabilidad y funcionalidad. El ponente va mostrando diferentes técnicas de ataque y pregunta a la audiencia si creen que Google lo considera bug o feature. Spoiler: muchas cosas que parecen bugs siguen siendo "así es como funciona" según Google.

Conceptos clave

• Todo en cloud funciona con permisos - Si tienes permisos para hacer algo, lo vas a poder hacer. Punto.
• Enumeración de permisos sin logs en GCP - Existe una API que te permite preguntar por permisos sin generar ningún registro de auditoría
  • Puedes hacer brute force de hasta 50 permisos a la vez
  • No requiere ningún permiso para usar la API
  • Malo para Blue Team, genial para Red Team
  • Google lo reportó como vulnerabilidad en febrero 2024... y sigue sin arreglarse
• GKE (Kubernetes de Google) y el grupo system:authenticated - Cualquier usuario autenticado en Kubernetes está en este grupo por defecto
  • Con credenciales de GCP puedes conseguir un token válido para cualquier clúster de GKE
  • Si ese clúster le ha dado permisos al grupo system:authenticated, entras directamente
  • Muchas empresas no sabían esto y daban permisos sin pensar
  • Google solo bloqueó el rol cluster-admin pero puedes asignar cualquier otro rol
  • Esto sigue siendo una funcionalidad, no lo han corregido del todo
• Race condition en Cloud Functions y servicios similares - Si tienes permisos de lectura/escritura en un bucket donde se guarda código:
  • Monitorizas cambios en el bucket
  • Cuando un admin actualiza código, tú metes tu backdoor antes de que se construya el contenedor
  • Funciona en Cloud Functions, App Engine, Composer
  • Ejecutar código en estos servicios = acceso a metadata = robar tokens = escalada de privilegios
  • Google lo considera funcionalidad, lo puedes seguir explotando
• Hardcoded credentials en Composer - Apache Airflow usa una clave para cifrar cookies
  • Por defecto usaba "temporary_key" (CVE de 2020)
  • Google decidió usar "sum_random_id" como string literal... alguien se olvidó de poner un random ID de verdad
  • Podías firmar tus propias cookies de admin si conocías la URL del Composer
  • Esta sí la corrigieron, ahora meten un random ID de verdad
• RCE vía variables de entorno - Casi todos los lenguajes de scripting miran ciertas variables de entorno que pueden ejecutar código arbitrario
  • Python: PYTHON_WARNINGS + BROWSER
  • También en Node, Lua, Ruby, Perl, Java, PHP
  • En servicios cloud puedes controlar variables de entorno
  • En Composer se lanza código en múltiples contenedores (DAG Processor, Triggerer, Worker, Scheduler) y puedes meter variables maliciosas

Desarrollo técnico

El tema de la race condition es especialmente interesante porque es agnóstico del cloud. El flujo básico es: admin cambia código → código se sube al storage → servicio construye contenedor con ese código. En ese medio segundo entre que se sube el código y se construye el contenedor, tú como atacante puedes pisar el código legítimo con tu backdoor. AWS lo hace mejor porque usa sus propios buckets internos donde el usuario no tiene acceso, pero Google usa los buckets del usuario, así que es vulnerable.

Las variables de entorno son otro vector que la gente no suele tener en cuenta. Si un servicio te deja meter variables de entorno custom y luego ejecuta código Python (por ejemplo), ya tienes RCE sin necesidad de tocar el código real. Esto es especialmente peligroso en Composer porque afecta a varios contenedores, no solo al que ejecuta tus DAGs.

Herramientas mencionadas

• BruteForce GC Permissions → Enumera permisos en GCP sin generar logs (ahora integrado en Cloud Pairs)
• Cloud Pairs → Herramienta genérica para averiguar permisos en AWS, GCP y Azure

Términos técnicos importantes

• GKE - Google Kubernetes Engine, el servicio de Kubernetes gestionado de Google
• Composer - Servicio de Apache Airflow dentro de GCP
• system:authenticated - Grupo por defecto en Kubernetes que incluye a cualquier usuario autenticado
• Race condition - Ataque que aprovecha la ventana de tiempo entre dos operaciones

Conclusión

Lo más flipante es que muchas de estas técnicas siguen funcionando porque Google las considera "funcionalidades" y no vulnerabilidades. La enumeración de permisos sin logs es brutal para un atacante: puedes saber exactamente qué tienes sin hacer ruido. El tema de GKE también es preocupante porque mucha gente asume que si un usuario no está dado de alta en su clúster, no puede entrar, pero la realidad es distinta.

Para Red Team esto es oro: tienes ataques que funcionan, que Google sabe que existen, y que no van a arreglar porque "así es como funciona el cloud". Para Blue Team... bueno, toca configurar bien los permisos y no asumir que Google te va a proteger de todo.

Más

• Probar estas técnicas en AWS y Azure para ver diferencias de implementación
• Revisar qué servicios de GCP usan buckets de usuario vs buckets internos
• Investigar más variables de entorno explotables en diferentes lenguajes
• Mirar si el bounty program de Google ha mejorado realmente este año como menciona el ponente